05 - 任务环境与选型
前置：不需要，本篇可独立阅读。读过 01 篇 会更清楚为什么强调可复现。
本篇回答：环境跑起来之后，用什么任务去训？现成的那些基准能不能直接拿来当训练 环境？有哪些坑是新手一定会踩的？
本篇会用到的词：
| 词 | 意思 |
|---|---|
| 评测基准（benchmark） | 一组固定的题目和评分方式，用来横向比较不同模型。它的设计目标是公平，不是可训练 |
| RLVR | Reinforcement Learning with Verifiable Rewards，可验证奖励强化学习。奖励由程序自动判定（测试跑没跑过），不需要人打分 |
| 奖励黑客（reward hacking） | 模型找到了让奖励变高但没真解决问题的捷径。比如直接改测试文件让它通过 |
| 数据污染 | 训练用的题目和评测用的题目重叠，导致评测分数虚高、不反映真实能力 |
| 留出集（held-out） | 专门留着不参与训练、只用来评测的那部分任务 |
| 环境漂移 | 同一个任务在不同时间跑出不同结果，通常来自上游依赖更新或外部 API 变化 |
| SWE-bench Verified | SWE-bench 中经人工确认「题目本身没问题、可解」的那个子集，是目前编码 Agent 最常被引用的评测口径 |
一、评测基准不等于训练环境
这是这一篇最重要的一句话，也是最常被搞混的一件事。
一个评测基准和一个训练环境，看起来都是「一堆任务 ＋ 一个打分器」，但设计目标相反：
直接拿评测基准当训练集的后果：你在 SWE-bench 上训，再用 SWE-bench 报分，这个分数没有任何意义。正确做法是训练集和评测集从一开始就分开，评测那部分永远不参与训练。
二、三类任务环境的现状
以下 star 数、协议与最近提交时间均为本文实测当天通过 gh api 获取。最近提交这一列请重点看 —— 这个领域项目更替很快，不少一度很热的项目已经停更。
2.1 代码与终端
| 项目 | ★ | 协议 | 最近提交 | 定位 |
|---|---|---|---|---|
SWE-bench/SWE-bench | 5,669 | MIT | 2026-08-18 | 事实标准的评测基准。用真实 GitHub issue 与其修复补丁，判定方式是跑仓库自带测试 |
harbor-framework/harbor | 4,426 | Apache-2.0 | 活跃 | 评测与改进 agent 的框架，SkyRL 与 verifiers 都已接入 |
harbor-framework/terminal-bench-1 | 2,543 | Apache-2.0 | 活跃 | 终端复杂任务基准，考察 agent 在命令行里的实际能力 |
SWE-Gym/SWE-Gym | 722 | Apache-2.0 | 2025-07-29 | 把 SWE-bench 那套改造成可训练环境的早期工作（ICML 2025）。已明显停更 |
R2E-Gym/R2E-Gym | 321 | Apache-2.0 | 2025-07-13 | 程序化生成环境 ＋ 混合验证器（COLM 2025）。已明显停更 |
注意 SWE-Gym 与 R2E-Gym 的状态。 它们是最早认真回答「怎么把编码基准变成训练环境」的两个项目，学术贡献很实在，但作为工程依赖已经不适合直接用了 —— 这类研究项目发完论文就停更是常态。判断能不能依赖一个环境项目，看最近提交比看 star 数有用得多。
2.2 操作系统与浏览器
| 项目 | ★ | 协议 | 最近提交 | 定位 |
|---|---|---|---|---|
xlang-ai/OSWorld | 3,099 | Apache-2.0 | 2026-08-12 | 真实操作系统里的开放式任务（NeurIPS 2024），多模态 agent 的主要评测场 |
ServiceNow/BrowserGym | 1,325 | NOASSERTION | 2026-07-17 | 网页任务自动化的 Gym 环境，接口沿用 Gymnasium |
这一类的共同难点是可复现性：真实网页会改版、真实系统有状态。要拿来训练，必须把外部依赖固化下来（本地镜像站、录制回放），否则就是 01 篇 2.4 节说的环境漂移。
2.3 工具使用与多环境
| 项目 | ★ | 协议 | 最近提交 | 定位 |
|---|---|---|---|---|
THUDM/AgentBench | 3,675 | Apache-2.0 | 2026-02-08 | 综合评测 LLM 作为 agent 的能力（ICLR 2024） |
sierra-research/tau-bench | 1,393 | MIT | 2026-03-18 | 客服场景的工具使用与规则遵循，特点是有「用户」这一方参与对话 |
WooooDyy/AgentGym | 830 | MIT | 2026-05-30 | 跨多种环境演化 agent（ACL 2025），一次覆盖多个任务域 |
PrimeIntellect-ai/community-environments | 254 | Apache-2.0 | 2026-08-04 | 社区贡献的环境集合，配合 verifiers 与 Environments Hub 使用 |
最后一个 star 数很低，但它代表的是一个不同的东西：环境作为可安装、可共享的包。这条路线如果走通，环境会像 PyPI 包一样被复用，而不是每个团队各写一套。
三、三个必踩的坑
3.1 奖励黑客：模型会改测试
编码任务里最典型的一幕：模型发现改代码很难，改测试文件很容易，于是直接把断言删掉，测试「通过」了。
应对不靠模型自觉，靠环境设计：
# ❌ 错误做法：把整个仓库交给模型，然后跑测 试
# 模型对测试文件有写权限，奖励就可以被直接伪造
run_tests(repo_dir)
# ✅ 正确做法：判定用的测试从模型改不到的地方来
# 1) 模型只在工作副本里改代码
# 2) 判定前，用原始版本覆盖掉所有测试文件
# 3) 再跑测试 —— 这样模型对测试的任何改动都不生效
restore_test_files(repo_dir, from_ref=ORIGINAL_COMMIT)
run_tests(repo_dir)
agent-lightning 的 README 里专门把「reward-hacking prevention」列为其开源流程的一部分，说明这在实践中是必须专门处理的一环，不是边角情况。
3.2 全或无的奖励学不动
一个只有 0 和 1 的奖励，在成功率只有 5% 的阶段几乎不提供信号 —— 95% 的 rollout 都是 0，模型无从知道哪条轨迹更接近正确。
常见的缓解手段：
| 手段 | 做法 |
|---|---|
| 分级奖励 | 把「跑通了几个测试」也计入分数，而不只看全过 |
| 过程奖励 | 对中间步 骤给分：定位到了正确文件、改动的函数对了 |
| 课程学习 | 先训简单任务，成功率上来了再加难度 |
| 任务筛选 | 剔除掉当前模型成功率为 0 和 100% 的任务 —— 这两类都不提供梯度 |
最后一条最便宜也最有效，很多训练流程会在每一轮动态做一次筛选。
3.3 环境漂移让实验没法比较
具体会漂的地方，以及对应的钉法：
| 漂移来源 | 怎么钉住 |
|---|---|
| 基础镜像里的包被上游更新 | 镜像按 digest 引用，不用 tag |
pip install 每次拉到不同版本 | 依赖全部锁版本，并预装进快照，训练时不联网装 |
| 任务依赖的外部 API 改了返回 | 录制回放，或本地起一个假服务 |
| 机器时区、locale、随机种子不同 | 统一写进环境模板，不依赖宿主机 |
02 篇讲的快照机制在这里有个额外好处：把初始状态固化成快照，等于顺手把上面前两条钉死了 —— 快照里装好的依赖不会因为下次训练而变。
四、选型判断
五、全专题结论
| 问题 | 答案 |
|---|---|
| 训练环境和运行时沙箱是一回事吗 | 不是。并发规模、生命周期、reset 语义、可复现性四处都不同（01） |
| 大规模环境平台在解决什么 | 镜像按需加载 、50 毫秒级起停、快照与 fork、内存超分（02） |
| 训练框架和环境用什么接口 | 三套方案划在 rollout 的不同位置上，且都没稳定，别写死（03） |
| 谁负责拉起环境 | 框架自管 / 沙箱平台 / 集群编排，取决于「环境是不是一台机器」（04） |
| 用什么任务训 | 训练集与评测集从一开始就分开；先确认奖励能自动判定（本篇） |
一条贯穿五篇的主线：这一层的所有工程努力，都是为了让几千张 GPU 不要等在 CPU 上。 判断任何一个设计值不值得，回到这一条就行。
← 回到 专题索引 · Agent Infra 板块总览